The technical field relates to data processing and in particular to diagnostic mechanisms for monitoring data processing operations.
There are a number of situations where it is desirable to keep track of what is occurring in a data processing apparatus, whether it be tracing a stream of instructions being processed, or data being manipulated, or monitoring the flow of data along a particular bus.
Tracing the activity of a data processing system whereby a trace stream is generated including data representing the step-by-step activity within the system is a highly useful tool in system development. Such tracing tools use a variety of means for tracing things such as the program flow and may include embedded trace macrocells which are present on the chip whose processing is being monitored. These are described in ARM Embedded Trace Macrocell (ETM) Architecture Specification, ARM IHI 00141 of December 2002.
In addition, data processor cores increase their operating frequency and processors having multiple cores are becoming more common and pose a problem for trace. For example in existing ARM® (registered trade mark of ARM Ltd.) processor cores and ETM protocols, a bit rate of about 1.2 to 1.6 bits per instruction processed is achieved with instruction-only trace. Therefore a 1 GHz processor processing one instruction per cycle would generate 1.2 to 1.6 gigabits per second of trace data. This data may need to be taken off-chip and stored in a buffer. Furthermore, multi-processor system introduce integer multiples to this data rate.
A full-on instruction and data trace stream, which outputs on every instruction processed the full state of the processor, is becoming prohibitively expensive. Thus, existing trace macrocells remove from the full state various pieces of data that can be inferred by a decompressor. For example, the program counter (PC) is not transmitted on every instruction, since instructions are processed sequentially, and it is further not transmitted on most branch instructions, since the target of a normal branch instruction can be inferred by examining the instruction in the decompressor.
However, approx ⅓ of the remaining data produced is for “indirect branch” data. That is, instructions that branch in the instruction stream where the branch target address cannot be detected and that cannot be determined from the instruction opcode. For these instructions, a form of compression is used to reduce the number of bits that are output, for example, only the changing bits of an instruction address are output. However, experiments show that even with such compression, on average each such instruction results in approximately 14-15 bits of data output.
In summary, although compression can be used to reduce the average number of bits used to trace an individual instruction, it may be that the nature of the trace data is such that compression is not easily achieved or very effective. It would therefore be desirable to reduce the amount of trace data produced without reducing the information sent.